Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs

The Year Ahead

March 2025 update.

Even as the world changes, the Wikimedia Foundation remains certain that we want our mission – to make and keep useful information from Wikimedia projects available on the internet free of charge – to be a multi-generational endeavor: we want free knowledge to continue to be available to many generations to come. To do this, we need to fuel volunteer growth, to enable volunteers to build trustworthy encyclopedic content, to fund our mission, and to evolve our offering to shape the changing internet. You can read more about those four strategic pillars.

The internet is changing quickly. New generations are getting information through social video and AI experiences, and, compared to older generations, fewer of them are aware of Wikipedia. We are seeing related declines in the number of people coming to our sites and the number of people editing. Meanwhile, platforms across the internet are depending on Wikimedia content to underpin their AI and search offerings. These dynamics are major challenges, but they make it clear why the reliable free knowledge that we create together is so important. The world needs a source of trustworthy, human-reviewed knowledge more than ever before, and Wikimedia projects are continuing to show that they can provide it.

To rise to these challenges in the coming year, we will build pathways for drawing upon Wikimedia content sustainably, and we’ll bring Wikimedia content to online social spaces where newer generations are spending their time. We’ll improve our own sites so that readers want to come back, engage deeply, and contribute in ways that are meaningful to them. And we’ll invest in our ability to experiment quickly with new technology, so that our pace of development can match the pace at which the world changes.

The Wikimedia Foundation develops and shares its Product & Technology plans early in the annual planning process. The annual plan is how we’ll pursue our mission in light of what the world needs from us at this moment. It is not a list of projects, but instead, a set of directions for problems to solve and impacts to achieve over the course of the year.

In building the plan, we look outside our movement at global trends, and we look inside our movement, taking in volunteer input through the Community Wishlist, the Product and Technology Advisory Council, and numerous conversations on- and off-wiki throughout the year. This year, the Foundation revamped the Community Wishlist from a once-a-year survey into an always-open intake process where user needs and project ideas can feed into the work of multiple teams at the Foundation. To achieve this, we grouped wishes into “Focus Areas” and have integrated three of those Focus Areas under key results in the annual plan.

Read below for the summary of our plans, and see our objectives and key results (OKRs) for more details. An “objective” is a high level direction that will shape the product and technology projects we take on for the next fiscal year. They’re intentionally broad, represent the direction of our strategy and, importantly, what challenges we’re proposing to prioritize among the many possible focus areas for the upcoming year. They represent the problem we are trying to solve, but not how we will solve it. Each “key result” represents a measurable way to track the success of its objective. We’re sharing this now so community members can help shape our early-stage thinking and before budgets and measurable targets are committed for the year.

In June, we will share the first “hypotheses” that Product & Technology teams at WMF will work on. Each hypothesis represents work that we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point.

Fuel volunteer growth

The community of volunteers is the unique engine behind the success of the Wikimedia projects, and we need it to be healthy and growing. But in this past year, we’ve seen continued declines in the number of new and returning editors to the projects. Meanwhile, we see an opportunity: new generations are eagerly participating in other online social spaces where they connect over shared topics of interest. In the coming year, we will make contribution appealing to new generations through expanding mobile-first, new ways to edit (“structured tasks”), and adding intelligent workflows that make constructive mobile editing easy for newer contributors (“edit checks”). In those sorts of features, we will thoughtfully use AI to strengthen volunteers in their work, always keeping humans in the loop and prioritizing transparency. For both new and experienced volunteers, we will build avenues to connect and work together on our sites – inspired by successful campaigns and WikiProjects – allowing them to find liked-minded editors and improve content related to their interests (aligned with this Wishlist focus area).

Deliver trustworthy encyclopedic content

As AI-generated material multiplies on the internet, the world needs trustworthy encyclopedic content more than ever. We want to increase the abilities of volunteers to both generate new content and to ensure that existing content stays trustworthy. To help volunteers generate new content, we’ll improve content creation features (such as the Content Translation Tool), so that smaller communities can cover vital content. And in the vein of keeping content trustworthy, we will help experienced volunteers better manage their growing workloads by extending the tools they use to find tasks that need their attention – making it easier for them to update articles and revert unhelpful edits (aligned with this Wishlist focus area).

We’ll also help functionaries defend our content by surfacing new signals (beyond IP addresses) that identify bad actors, allowing users to be blocked in ways that minimize erroneous blocking of good-faith editors.

To deliver encyclopedic content to a new generation, we will build features that help new kinds of readers understand articles easily, help them find information they’re interested in, and allow them to participate actively as they read. These changes are meant to encourage new Wikipedia readers to become dedicated Wikipedia readers, and some of them to become donors (aligned with this Wishlist focus area).

Delivering trustworthy content also means supporting a “knowledge as a service” model, where the whole internet draws on Wikimedia content. In this model, our infrastructure is not just a valuable resource for humans coming to our website, but also for search and AI companies, which access our content automatically as a foundational input to and output from their products. These kinds of companies represent just one of many uses that increasingly place an unsustainable load on our infrastructure. In the last year, a significant increase in request volume coming from scraper tools and bots has made it more urgent for us to course-correct this trend. We need to establish sustainable pathways for developers and reusers to access knowledge content so that humans are prioritized over bots.

Fund the future of ‘free’

The Product & Technology department plays an important role in ensuring that our movement is sustainable. In the coming year, we will partner closely with the Fundraising team so that our donors have an increasingly clear and rewarding experience. On our sites and mobile apps, we will build opportunities for readers to express their appreciation for Wikipedia through donating, and we will build new ways for donors to feel recognized so that they continue their donations year after year.

Shape a changing internet

In order to bring free knowledge to everyone in the world, we need to meet them where they are, with the experiences that help them learn. People aged 18-24 have lower awareness and usage of Wikipedia than the generations that came before them. They largely learn from and interact with shortform video platforms, trusted online personalities, social gaming experiences, and, increasingly, AI applications. This year, we will be making Wikipedia available for those audiences in the places they spend time online, so that they know Wikipedia as a source of trustworthy and human-created knowledge. We will grow our presence in popular video platforms, spreading Wikipedia content and generating community in those spaces. And we’ll explore ideas for bringing Wikipedia knowledge to gaming and social platforms.

Next steps

Taken together, we believe that this plan meets a crucial moment in the history of the internet, setting us up to ensure that free knowledge content continues to be accessible to and shaped by all generations. Our objectives and key results show the structure and contents of this plan in more detail, and we look forward to hearing questions and ideas from the broader community.

Product and Technology Objectives

The objectives presented here are in draft form and are open for comments and discussion.

The Objectives represent a high level direction.
The "Key Results" (KRs) represent a measurable way to track the success of their objectives.
The underlying "Hypotheses" for each KR represent the actual work we are doing to try to achieve the associated key results. They will be updated in this document and on the relevant project or team's wiki pages as insights are gained throughout the year.
is for work the Foundation is prioritizing under the Community Wishlist.

Wiki Experiences (WE)

Contributor Experiences (WE1)

Objective: Contributions increase because volunteers are offered compelling opportunities and understand their impact. Discuss
- Context: This objective will be the foundation for delivering on the new contributor strategy with its 3 pillars: 1) offering volunteers a centralized way to organize their on-wiki activity, 2) providing smaller, discrete tasks to create more clarity and help volunteers achieve their potential, and 3) making contribution more meaningful. In FY25/26, we plan to deliver the basic infrastructure to help volunteers organize their on-wiki activity in a centralized way, starting with interventions specifically focused on experienced editors and moderators. In subsequent years we'll add interventions across all contributor roles and include more problem spaces. Additionally, we'll continue to invest in Edit Check and Structured Tasks, building a foundation for how to use AI in a scalable way, both as guidance during the editing process and as a way to point volunteers towards compelling opportunities. And lastly, we will invest in making the impact volunteers have more visible to create a more meaningful experience for them.
  - Key result WE1.1: Increase constructive edits [i] by X% for editors with less than 100 cumulative edits, as measured by experiments by the end of Q2.
    i. "Constructive edits" = edits that are not reverted within 48 hours of being published
    - New(er) volunteers struggle to start editing successfully. Particularly, people using mobile devices where screen space is limited and attention is often fragmented.
    - Some grow tired of the context, patience, and trial and error required to contribute constructively. Others have yet to encounter a compelling opportunity to try.
    - WE 1.1 will address these issues by:
      1. Surfacing edit suggestions
      2. Offering actionable in-edit guidance
      3. Building more task-specific editing workflows
    - At the core of these efforts is the need for scalable ways to detect how in-progress edits and existing content could be improved. To grow this capacity, we will continue to experiment with machine learning to learn how AI can help us identify Wikipedia policy issues.
  - Key result WE1.2: Increase in the number of collaborations on the wikis by X% YoY by the end of Q3.
    - Contributors often struggle to find opportunities to collaborate with one another, especially around the topics and tasks that they care about. This can lead to a feeling of being alone on the wikis for newcomers, and it can lead to burnout for experienced editors. Additionally, the impact of collaborative activities is often unclear, which can lead to less people wanting to join, organize, or support collaboration on the wikis.
    - We want to make the value of collaboration more clear by doing the following:
      1. Create new ways to share the impact of collaborative activities on the wikis
      2. Begin collecting movement-wide data on the impact of collaborative activities
      3. Set up the basic infrastructure to track collaborative contributions, so we can provide innovative new ways to recognize and reward contributions in the future
    - Collaborations will be measured by new activities created via Event Registration in the CampaignEvents extension. The goal is that, by the end of this KR, we will have more users of the extension tools and new ways of surfacing collaboration impact. This will put us in a good place to connect our existing infrastructure to other ways of recognizing and rewarding work on the wikis (such as the impact module, thanks, etc).
    - Wishlist focus area: Community Wishlist/Focus areas/Connecting Contributors
  - Key result WE1.3: By the end of Q4, there has been an X% increase in moderation actions done by people who are new to that type of moderation.
    - As part of our efforts to create more clarity for contributors, we believe that we can do a better job of surfacing contribution opportunities to volunteers. We will test this theory by surfacing specific moderation activities (details to be determined) to contributors who are new to that type of moderation action, with the goal to get more contributors engaged in moderation tasks. We envision this to live in a place that's central to the volunteer's activities, and this KR will serve as a means for us to explore this concept and determine the right place for these kinds of interventions.
    - Our overall aim as described in the KR is not to simply broaden the pool of moderators, but to focus our efforts on engaging currently active editors with opportunities they might not be familiar with. X% is a placeholder value, pending measurement of a baseline of how frequently active editors engage with new moderation workflows.
    - "Moderators" will follow the definition started in Research:Develop a working definition for moderation activity and moderators, though followup work would be needed to narrow down the quantitative definition.
    - Wishlist focus area: Community Wishlist/Focus areas/Task prioritization

Vital Knowledge (WE2)

Objective: Make more vital knowledge available and well illustrated across languages and topics. Discuss
- Objective context: This objective will drive content growth that is responsive to both contributors’ interests in particular topics and languages, and reader demand for vital knowledge that is well illustrated. Vital knowledge is a set of articles that delivers the breadth and depth of topics needed for a usable Wikipedia language project. It is defined by communities with reference to notability, relevance, predicted readership, and connections between articles.
- We will take a socio-technical approach, improving the effectiveness of features, tools, and social processes. We will build on high-impact product features like suggested tasks, media search, and content translation but also facilitate the onboarding and development of smaller language Wikipedias. We will support the Wikimedia organizers who recruit, train, and support contributors to work on shared content goals through collaborative setups like WikiProjects and campaigns. (We estimate that at least 300 organizers are active each quarter.) We will also develop relationships with the most relevant publishers to remove barriers to source materials. (We currently have partnerships with more than 100 of the world’s top subscription-only databases.)
- To ensure our interventions have a positive impact on vital knowledge, we will measure both the increase of community-prioritized content and the quality of that content, looking at factors like reversion rates and the number of citations and images.
  - Key result WE2.1: By the end of Q2, implement 3 interventions that help contributors to improve the state of vital content on their Wikipedias.
    - This KR will highlight content gaps within editing mechanisms, such as the discovery of images on Wikipedia, content translation, and guided creation of new articles. We will also implement and test a socio-technical intervention to support content creation activity for small language communities. Success will be measured within each hypothesis.
  - Key result WE2.2: By early Q3, 10 Wikifunctions are created by Wikimedia communities to create content on at least 10 Wikimedia projects.
    - Currently, tools that can create content scalably are not accessible to all Wikipedias. This includes templates and modules, which have been used on larger Wikipedias to create and maintain content. Wikifunctions can make these tools available to many more projects, and local communities wouldn’t have to create or maintain these tools themselves.
    - Initial capabilities of Wikifunctions can include:
      - Conversion functions (in plain wikitext) to provide more comprehensive content which otherwise wouldn’t exist because of the effort involved
      - Opening sentences and paragraphs for certain articles (in plain wikitext), which can ensure more consistency and correctness across wikis. Examples for that include articles for years in many wikis, or biographies on Italian Wikipedia.
      - Content that can use Wikidata and automatically maintain the content when the data is updated, e.g. the population of a city or the age of a person.

Consumer Experiences (WE3)

Objective: Readers from multiple generations engage, and stay engaged, with Wikipedia, leading to measurable increases in retention and donation activity. Discuss
- Objective context: This objective will focus on retaining new readers through innovative content formats, core audiences through strengthening familiar reading experiences, and ensuring long-term sustainability by deepening reader connections and diversifying donations. It will include a continuation of our work into making content easier to discover through new and more experimental features such as AI summaries or personalized rabbit holes. It will also include work on retaining and improving the quality of the reading experience deeper in the reading funnel and on exploring reading curation through reading lists and other non-editing participation. For donors, this work will continue focusing on diversifying revenue sources from within the platform.
  - Key result WE3.1: Increase retention of logged-out readers by 5% on apps and 3% on web, as measured via A/B testing, through experimenting with ways of learning and engagement by the end of Q4
    - This KR will focus on continuing to invest in experiences that optimize for new ways of browsing and learning content, often through the use of new technologies and formats - presenting existing content in new and engaging ways. In this FY, we would like to continue experimenting with new features while also focusing on scaling successful experiments across wikis and platforms. The work in the KR will span across the mobile and desktop website, as well as the iOS and Android apps and focus on content discovery (browsing entry points and recommendations) and adaptable learning formats (machine-assisted summaries, content remixing).
    - Wishlist focus area: New consumer experiences
  - Key result WE3.2: Increase number of donations through non-banner or email methods by 5% YoY through product interventions that foster deeper connections and reduce friction for donors by the end of Q2
    - This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team
  - Key result WE3.3: Increase the retention of account-holding readers on apps and web by 5% by the end of Q4, as measured via A/B testing
    - This KR will focus on improving the reading and learning experience for existing and experienced readers, with the goal of retaining our current audience and deepening their connection to the site so they can learn more, as well as be ready and open to take paths towards donation and editing. Work here will focus on improving the reading experience on the web and apps (readability improvements, better navigation and discovery), as well as building out and iterating on our curation and personalization offerings (Reading lists, personalized suggestions, user and article history, etc)
  - Key result WE3.4: By end of Q3, deploy one small-scale cache site that meets our current quality of service and security standards as per our current cache site deployments
    - This KR will focus on proving the concept that we can improve website performance and reduce latency for our readers by simplifying our caching infrastructure and improving the processes for a caching site deployment by reducing the baseline deployment time from about one year on average to a quarter at most. The focus here will be to complete the simplification, deploy a PoC, conduct a security review and complete a decision brief on whether to proceed with deploying our edge caches in public clouds. Decreasing latency can lead to a proven increase in pageviews and a more geographically diverse reader base.

Trust & Safety (WE4)

Objective: Develop enhanced abuse prevention capabilities to defend our projects against widespread and targeted threats while strengthening the privacy and safety protections for our users. Discuss
- Objective context: Some facets of our abuse fighting capabilities are in need of an upgrade. IP-based abuse mitigation is becoming less effective, several admin tools are in need of efficiency improvements, and we need to put together a unified strategy that helps us combat scaled abuse by using the various signals and mitigation mechanisms (captchas, blocks, etc) in concert. Over this year, we will begin making progress on the largest problems in this space. Furthermore, this investment in abuse protection has to be balanced by an investment in the understanding and improvement of community health, several aspects of which are included in various regulatory requirements.
  - Key result WE4.1: By Q4, we will have an easily discoverable, in-context incident reporting system deployed on all our projects.
    - Ensuring user safety and well-being is a fundamental responsibility of our platform. Many jurisdictions have regulations that require online platforms like ours to monitor and take action against harassment, cyberbullying and other harmful content on their platform. Failing to address these may expose platforms to legal liability and regulatory sanctions.
    - We want to empower our users to be able to report immediate threats of harm through an easily discoverable and intuitive reporting mechanism to ensure we are able to learn about such incidents and take prompt action where necessary. This is a step towards making our users feel safe when contributing to our platform. We are doing this by implementing an Incident Reporting System on our wikis.
  - Key result WE4.2: Improve the precision of anti-abuse tooling, as measured by an X% reduction in call-to-action interactions in the mobile editing block notice.
    - We want to improve existing capabilities and deliver new tools that enable more precise and effective blocking of bad actors. One way of measuring our effectiveness is by looking at interactions with the "call to action" link that is present in the mobile editing interface when a user is blocked. An assumption is that users who interact with this link are more likely to engage with the link due to collateral damage from IP blocks. If we see a reduction in the number of interactions with the call to action link, it is likely that we are also reducing collateral damage from IP blocks. Work in this KR involves new/improved signals in AbuseFilters, improved sockpuppet and ban evasion detection and mitigation, surfacing information about the potential for collateral damage, strengthening bot detection, and greater efficiency in anti-abuse tooling interfaces.
  - Key result WE4.3: Reduce the number of large-scale attacks that require SRE human intervention by 50% (compared FY-over-FY)
    - The evolution of the landscape of the internet, including the rise of large-scale botnets and more frequent attacks have made our traditional methods of limiting large-scale abuse obsolete. Such attacks can make our sites unavailable by flooding our infrastructure with requests, or overwhelm the ability of our community to combat large-scale vandalism. This also puts an unreasonable strain on our high privilege editors and our technical community.
    - We urgently need to improve our ability to automatically detect, withstand, and mitigate or stop such attacks.
    - This year we will focus mostly on automating detection of IP addresses and networks that regularly engage in attacks against us, and reduce the amount of load those persistently-harmful entities are allowed to place on our systems.
  - Key result WE4.4: By Q2, Temporary Accounts are deployed to 100% of our projects such that exposure of personally identifiable information of our unregistered editors is available to less than 0.1% of registered users.
    - Temporary accounts aim to improve the privacy and thereby, safety of our unregistered editors by shielding their personally identifiable information (IP address) from public view and limiting access to only those who need it for patrolling purposes. Besides being a major improvement to user safety, this project is also important to comply with various regulatory requirements.
  - Key result WE4.5: Conduct and publish an AI risk and opportunity assessment for Trust & Safety, identifying potential threats and opportunities, along with recommended mitigation or adoption strategies for Wikimedia projects.
    - AI is making rapid advances across the Internet. There are many opportunities as well as threats that emerge with AI becoming ubiquitous. For example, content is easier and cheaper to generate, but moderation is more strenuous. Similarly, research can be carried out with much less effort but AI hallucinations are harder to identify. People remain central to AI as a source of information but AI often lacks robust safety measures.
    - This project aims to do an assessment of AI’s impact on Trust & Safety aspects of Wikimedia’s ecosystem. This can include:
      - Publishing an AI impact assessment
      - Identifying product opportunities
      - Identifying models we could use and developing a plan to integrate them

Responsible Use of Infrastructure (WE5)

Objective: Developers and reusers access knowledge content in curated pathways, ensuring the sustainability of our infrastructure and responsible content reuse. Discuss
- Objective context: This objective will focus on establishing pathways for responsible content reuse.
- Wikimedia hosts the largest collection of human-curated knowledge on the web. This has made our knowledge infrastructure an invaluable destination not just for humans, but also for automatic data consumers. Our content feeds into search engines, social media platforms, ecommerce, and ever since the rise of AI, is used to train large machine learning models. Consumers source data by scraping pages, using the APIs, and downloading content – commonly without attribution. In the world of unauthenticated traffic we can’t reliably differentiate one user from another, which greatly limits our ability to enable and enforce responsible use of our infrastructure: How can we continue to enable our community, while also putting boundaries around automatic content consumption? How might we funnel users into preferred, supported channels? What guidance do we need to incentivise responsible content reuse? How can we drive towards a cohesive developer experience, and build products that meet the needs of volunteer developers, staff and reusers alike? While these questions are not all new, the urgency of addressing these has grown exponentially: Since 2024 we’re observing a dramatic rise in request volume, with most of the increase coming from scraping bots collecting training data for AI-powered workflows and products. The load on our infrastructure is not sustainable and puts human access to knowledge at risk: We need to act now to re-establish a healthy balance, so we can effectively support the Wikimedia projects and enable the sustained success of our mission.
  - Key result WE5.1: By the end of Q4, 50% of automated traffic can be attributed to a known developer or application, enabling us to increase the sustainability of our infrastructure and prevent abuse.
    - We currently have limited ways to identify who is responsible for automated traffic and, unlike on-wiki, limited ways to contact users or regulate their access. We have seen a significant increase in the volume of external automated traffic, which is not sustainable for us and puts human access to knowledge at risk. We aim to increase the percentage of automated traffic that is attributed to a known account, by requiring authentication and authorization based on tiered levels of access for high volume scraping and API use. This will help us to identify who is reusing content at scale, enabling us to protect our infrastructure and improve governance around fair use, whilst more effectively meeting their needs. We will also explore how to better support the technical community with a more cohesive developer experience that protects preferential access for community members and enables new functionality for developers.
  - Key result WE5.2: By the end of Q4 2025, X% of Wikimedia web API endpoints will be supported by common infrastructure that enables us to provide a more consistent developer experience, reduce developer burden, and improve approachability of Wikimedia web API experiences.
    - We aim to improve the experience and sustainability of our developer pathways by offering more consistent, stable, and discoverable web APIs for all Wikimedia developers. We will simplify our API offerings by introducing more centralized infrastructure for core API capabilities, allowing us to have consistent pathways and governance for: OpenAPI specs and documentation, developer identification and access controls, API policy enforcement, routing, versioning, and error handling. By streamlining our API offerings, we will make it faster, easier, and more delightful to build tools, bots, research projects, and features that serve the Wikimedia mission. This approach supports the multi-generational future of the mission by reducing API infrastructure maintenance costs, increasing visibility and access control for combating bad actors, and fostering a stronger developer community.
  - Key result WE5.3: By the end of Q2, new attribution guidelines for web, apps, voice assistants, and LLMs will be published and linked across Wikimedia sites, with at least two reuse demos deployed that drive measurable engagement (e.g., X% clickthrough rate to guidance), and at least one external reuse partner adopting best-practice attribution.
    - To increase proper attribution of Wikimedia content, we will provide clear best-practice guidance that promotes responsible reuse. This includes creating attribution guidelines for key platforms (web, apps, voice, multimedia) and showcasing at least two practical examples highlighting exemplary applications of Wikimedia content. Examples of outputs include encouraging media organisations to credit Wikimedia Commons images, search engines to surface relevant Wikimedia data more effectively, or AI assistants to integrate Wikipedia knowledge in transparent and responsible ways that increases trust in their reliability. Strengthening attribution practices not only increases public awareness and drives engagement back to Wikimedia projects, but also helps establish responsible and novel ways of remixing knowledge, and deterring misuse.
  - Key result WE5.4: Reduce the amount of traffic generated by scrapers by 20% when measured in terms of request rate, and by 30% in terms of bandwidth
    - Scraping has always been here: the search engines have relied on Wikipedia to provide information to their users for decades; however lately there’s another big motivation to scrape our data: it’s the largest curated, multilingual set of knowledge content you can find on the internet and it’s a fundamental tool to train large language models. This is true both for our encyclopedic content and our multimedia repository, Wikimedia Commons, which is invaluable for machine learning models that generate images.
    - As a consequence, over the past year, we saw a significant increase in the amount of scraper traffic, and also of related site-stability incidents: Site Reliability Engineers have had to enforce on a case-by-case basis rate limiting or banning of crawlers repeatedly to protect our infrastructure. Scraping has become so prominent that our outgoing bandwidth has increased by 50% in 2024. What's more, a recent analysis showed that at least 65% of our most expensive requests (the ones that we can’t serve from our caching servers and which are served from the main databases instead) are performed by bots.
    - Our computing resources are extremely limited compared to the amount of traffic we make, so we have to prioritize who we serve with those resources, and we want to favour human consumption, and prioritize supporting the Wikimedia projects and contributors with our scarce resources.

Accelerate Path to Product Outcomes (WE6)

Objective: Wikimedia developers quickly and confidently get their products out to end users. Discuss
- Objective context: To be effective in achieving the 4 strategic pillars, Wikimedia developers need to be spending their time and effort on high-leverage activities that result in delivering quality products as early as possible. Overly complicated workflows, lack of standard tooling, and unsustainable system components get in the way of those outcomes.
- This work builds on the momentum we've picked up the last 2 annual plans evolving MediaWiki as a platform and the software supporting its development and deployment. The work for this year will focus on providing more reliable developer environments, simplifying pre-production workflows, and reducing platform and infrastructure risks.
  - Key result WE6.1: By the end of Q4, the number of train-blocking bugs that make it beyond test wikis is reduced by 10%
    - In 2024, there were 144 times developers had to revisit work because there was an emergency preventing the deployment of MediaWiki. In many of those cases, the bugs were caught after deploying to testwikis, meaning the issue reached a potential audience of billions of users. We can't control the fact that bugs will exist, but catching them earlier would mean less hero work is needed. It would also build up confidence in developers that when something goes to real production, there won't be a fire.
    - We will catch these bugs earlier by providing environments needed by developers to confidently deliver and test their code throughout the development and deployment lifecycle. We also need to ensure that these improvements do not come at the cost of developer velocity.
  - Key result WE6.2: By end of Q4, 4 steps from the production readiness review checklist can be executed without SRE intervention
    - Getting a new service or feature deployed in production currently depends on a list of 24 steps for which each step typically needs support from SREs. We established the SRE ambassador program to intervene earlier in the development cycle and build up capacity within the development teams themselves, but many of the tasks should be entirely self-serviceable. Currently, this amounts to work that is manual, repetitive, automatable, and that scales linearly with the number of development teams. This is not sustainable for the SRE team in the long run.
    - In the past, much of this work was abstracted from development teams by maintaining a set of shared common libraries and best practices to interact with our platform. These were abandoned when we moved to our new Kubernetes infrastructure and do not have a direct replacement. By providing similar libraries, documentation, and training that apply to the way we build and deploy things today, we believe we can reduce the amount of involvement needed from SRE before deploying a new service or feature to production.
  - Key result WE6.3: By end of Q4, 100% of Wikipedia page views are served through Parsoid
    - Parsoid offers enhanced capabilities for wikitext evolution and future-proofing the platform. Maintaining two parsers concurrently is not sustainable in the long term, as it increases technical debt and complexity. Additionally, the success of some new projects like Wikifunctions depends on Parsoid being widely available.
    - We have been scaling up the rollout to smaller projects and this year we will be ready for the Wikipedias. Serving all Wikipedia page view reads through Parsoid is the most important next milestone. In addition to the rollout itself, this work also includes resolving performance issues and communicating effectively about the impact to readers and editors.
  - Key result WE6.4: By end of Q2, at least two identified risks that threaten our ability to continue deploying or scaling the wikis have been mitigated or reduced to an acceptable level
    - Through a few targeted initiatives, we will reduce or mitigate several scalability, reliability, or security risks that we have identified as a likely potential threat to the growth and sustainability of our platform and our public projects.
    - For example, we will be refactoring the structure of the core databases of Commons to ensure its growth will not be limited by the capacity of available server hardware within the next few years. We will also be upgrading PHP, the programming language powering MediaWiki and related services, to a more modern version. Other risks identified will likely require implementing additional security measures to protect and harden of our infrastructure.

Signals and Data Services (SDS)

Metrics (SDS1)

Objective: Decision makers use more trustable and timely human and bot traffic data to inform product and strategic decisions. Discuss
- Objective context: The rise of automated traffic in the past couple of years has degraded our confidence in traffic metrics. In addition, multiple data issues have emerged, and time-to-identification and resolution are too high. These issues slow down and limit our ability to evaluate human and bot traffic patterns, which are critical inputs for planning and product decisions.
- In FY25-26, we will focus on our traffic metrics as a case study for resolving the data quality gaps in our current pipelines, setting up infrastructure and processes for monitoring and resolving data quality issues, and delivering tools that enable decision makers to understand trends around human and automated traffic.
  - Key result SDS1.1: By the end of Q1, analysts who use pageview metrics can access baseline measures of data quality and automated traffic detection
    - Through the hypotheses explored in this KR, we aim to identify gaps in our current automated traffic detection heuristics and understand where they fail to properly categorize pageview traffic. These insights will inform improvements to the pipelines that generate and classify pageview metrics. Additionally, we will define data quality metrics to monitor and measure improvements in data accuracy.
    - This KR will lay the groundwork for a follow-up KR (KR2) focused on implementing the necessary pipeline improvements identified here. The data quality metrics established in this phase will serve as benchmarks to assess the effectiveness of those future enhancements.

Experimentation Platform (SDS2)

Objective: Product managers can quickly, easily, and confidently evaluate the impacts of product feature changes in Wikipedia. Discuss
- Objective context: To enable and accelerate data informed decision making about product feature development, product managers need an experimentation platform in which they can define features, select treatment audiences of users, and see measurements of impact. Speeding the time from launch to analysis is critical, as shortening the timeline for learning will accelerate experimentation, and ultimately, innovation. Manual tasks and bespoke approaches to measurement have been identified as barriers to speed. The ideal scenario is that product managers can get from experiment launch to discovery with little or no manual intervention from engineers and analysts.
- We are focused on Wikipedia for the next fiscal year because that is where Core Experiences is interested in experimentation (the organizational strategy has us doubling down on Wikipedia), and because it allows us to focus and signal more clearly which teams and projects we are engaging with. Other teams have used the experiment platform components and may continue to do so, but that use won’t be the focus of this objective.
  - Key result SDS2.1: By the end of Q2, reduce the time it takes a product manager to conduct a two-variant A/B test for a reader feature on Wikipedia to under 6 weeks (excluding duration of data collection).
    - Currently, product managers face a 10+ week experiment cycle – from hypothesis to results, not including duration of experiment – due to dependencies on analysts and engineers, manual processes, and data trust issues. These dependencies delay learning, iteration, and innovation. A product manager empowered by and educated on our platform's self-service capabilities will be able to confidently make a product decision informed by trustworthy data in under 6 weeks (excluding treatment implementation and duration of data collection).

Future Audiences (FA)

Future Audiences (FA1)

Objective: The Wikimedia Foundation is equipped with recommendations on strategic investments to pursue that help our movement serve new audiences in a changing internet. Discuss
- Objective context: Due to ongoing changes in technology and online user behavior (e.g., increasing preference for getting information via social apps, popularity of short video edu-tainment, the rise of generative AI), the Wikimedia movement faces challenges in attracting and retaining readers and contributors. These changes also bring opportunities to serve new audiences by creating and delivering information in new ways. However, we as a movement do not have a clear data-informed picture of the benefits and tradeoffs of different potential strategies we could pursue to overcome the challenges or seize new opportunities. For example, should we...
  - Invest in large new features like chatbots?
  - Bring Wikimedia's knowledge and pathways to contribution to popular third-party platforms?
  - Something else?
- To ensure that Wikimedia becomes a multi-generational project, we will test hypotheses to better understand and recommend promising strategies – for the Wikimedia Foundation and the Wikimedia movement – to pursue to attract and retain future audiences.
  - Key result FA1.1: As result of Future Audiences experimental insights and recommendations, by the end of Q3 at least one objective or key result owned by a non-Future Audiences team is present in the draft for the following year's annual plan.
    - Since 2020, the Wikimedia Foundation has been tracking external trends that may impact our ability to serve future generations of knowledge-consumers and knowledge-contributors and remain a thriving free knowledge movement for generations to come. Future Audiences, a small R&D team, will:
      - Perform rapid, time-bound experiments (aiming for at least 3 experiments per fiscal year) to explore ways to address these trends
      - Based on insights from experimentation, make recommendations for new non-experimental investments that WMF should pursue – i.e. new products or programs that need to be taken on by a full team or teams – during our regular annual planning period.
    - This key result will be met if at least one objective or key result that is owned by a team outside of Future Audiences and is driven by a Future Audiences recommendation appears in the draft annual plan for the following fiscal year.

Social video (FA2)

Objective: Young (<25-year-old) people love, learn from, engage with, and share Wikipedia content on platforms where they like to spend time online. Discuss
- Objective context: Future Audiences experimentation with short video this fiscal year has shown that we can reach younger audiences at scale on these platforms, but our Brand Health data is showing that our current investment is not enough to counter the decline in awareness and affinity with Wikipedia among Gen-Z-aged audiences.
- In order to ensure that we effectively reach and engage this generation, we believe that we will need to engage in a variety of tactics, and significantly increase our engagement in areas such as paid and influencer marketing, creative campaigns, being responsive to trends and increasing our level of experimentation on these channels.
- We expect that the challenges we are facing will require a more substantial investment to help us overcome them, particularly in Communications and Marketing efforts to create engagement, as well as cross-departmental collaboration on creating new products and experiences geared at increasing the presence of Wikipedia's brand and content on these platforms.
  - Key result FA2.1: Generate 5,000,000 views from short-form video content across all owned channels by the end of H1.
    - This year, we achieved a reach of approximately 1 million views within 3 months of launching short videos on the @Wikipedia channels on TikTok, Instagram, and YouTube. By the start of next fiscal year, we expect more followers on our owned channels and more insights into effective/engaging content that we can put into practice to reach even more viewers.
    - By setting an ambitious goal in the first half of the year, we hope to drive toward more significant impact, allow for the creation of new strategies/processes to facilitate the work, and be able to advocate for additional resources to meet this goal.
  - Key result FA2.2: Iterating on actual views baseline achieved at the end of H1, by the end of H2 achieve a 10% increase on views achieved in H1.
    - While we are aiming for 5 million views in the first half of the year, we may land significantly above or below this initial goal. In the second half of the year, we will have an actual (vs the projected goal of 5 million) baseline, more learning about effective strategies/resourcing needs, so we expect to be able to improve on this initial baseline.
  - Key result FA2.3: Launch a product off-platform aimed at future audiences' new methods of learning/media consumption and bring it to market through a collaborated product branding and marketing campaign.
    - Future Audiences typically works on small-scale experiments with minimal/organic marketing. This year, we would like to reserve time for a more scaled-up new product + marketing campaign targeting younger audiences off-platform.

Product & Engineering Support (PES)

Product & Engineering Support (PES1)

Objective: WMF Product and Engineering teams are more effective due to improved processes, fostering a positive shift in our culture. Discuss
- Objective context: This objective is about making The Wikimedia Foundation’s ways of work faster, smarter, and better. It’s all about how we work. This means less friction and obstacles (inefficiencies and errors) in processes, and achieving impact quicker. This Objective is also about learning ways of work that can be adopted across the department and organization.
  - Key result PES1.1: By end of Q2, define SLOs for 6 production services based on a prioritization rubric that aims to maximise our learning of how to define and use SLOs to make informed decisions regarding prioritization of reliability related work by stakeholder teams.
    - A Service Level Objective (SLO) is an agreement between stakeholder teams on a target level of service (reliability/performance) that teams collaborate to meet (and not greatly exceed). For example, it helps determine when reliability or performance work should to be prioritized or deprioritized by a development team, or what constitutes a problem. Teams need to care about identifying what is immediate (alerting/incident response/critical bugs) versus what isn’t. The goal is to reduce friction across functions by negotiating targets and informing shared and clear prioritization.
  - Key result PES1.2: 80% of Wishlist-based requests submitted during Q1 and Q2 receive an initial response within 14 days, resulting in a status change.
    - We learned in FY2024-5 that wishes can inform strategic work (via focus areas), and that processing and evaluating wishes is a collaborative effort. We also learned we can streamline how we process wishes as a foundation, and that we need to better communicate the status and foundation's position on any given wish.
    - In this KR, we will run experiments to improve the speed and efficiency of processing wishes, increase the number of foundation staff evaluating and commenting on wishes (with less effort), and experiment with frameworks to evaluate wishes against agreed-upon product goals. Additionally, we want to experiment with targeted wishlist brainstorming, where community-led ideas align to team and product goals. Finally, we will evaluate and measure community sentiment of the wishlist.
  - Key result PES1.3: Two early-stage cross-departmental experiments, validated by our external consumer, donor, and contributor audiences, are incorporated by the Foundation into the annual plan.
    - This work is about creating experiments and experimentation processes for adoption across our organization.
    - The Foundation strengthens a culture of cross-departmental experimentation by incorporating two validated, early-stage experiments into its annual planning. This initiative fosters collaboration beyond the Product & Technology department feature teams, encouraging more innovation with other departments in the organization (such as Communications and Advancement). By seeding untested newer ideas and streamlining processes for experimentation, teams enhance productivity and scale impact. Success is measured by completing two cross-departmental experiments per year, integrating them into future OKR work, and increasing adoption of experimentation practices. Examples of outputs are new prototypes to increase new editors’ growth and productivity, to experimental features that deepen reader and donor connection to Wikipedia. One specific opportunity identified is connecting small feature explorations to celebrate Wikipedia’s 25th birthday.

Planning Together

January 2025 update.

The Annual Plan is the Wikimedia Foundation’s description of what we hope to achieve in the coming year. We work hard to make the plan participatory, aspirational and achievable. Every year, we ask contributors to share their perspectives, hopes and specific requests as we shape the plan. Some of the ways we seek that input are through product team conversations with communities, the Community Wishlist, community conversations like the Commons conversation series, at conferences and through wiki pages like this one.

For our next annual plan, from July 2025 to June 2026, we are thinking about how we can best serve a multi-generational vision, given rapid changes in the world and the internet and how that affects our free knowledge mission.

As I said last year, we need to focus on what sets us apart: our ability to provide trustworthy content even as disinformation and misinformation proliferate around the internet and on platforms competing for the attention of new generations. This includes ensuring we achieve the mission to assemble and deliver the sum of all human knowledge to the world by expanding our coverage of missing information, which can be caused by inequity, discrimination and bias. Our content needs to also serve and remain vital in a changing internet driven by artificial intelligence and rich experiences. And finally, we need to find ways to sustainably fund our movement by building a shared strategy for our products and fundraising so that we can support this work for the long term.

To make choices and tradeoffs about where to focus our efforts in the coming year, we pulled together questions and thought about how to allocate our finite resources toward achieving the most impact.

If you are interested specifically in what features or services the Product and Technology department will build based on priorities set here, there will be time in March to comment on specific objectives and key results. (Here are the key results for the current annual plan, for reference.)

If you want to think about the challenges and opportunities in our technical environment and the direction we should set in the next annual plan, please consider the questions below with us.

We continuously take in information about these questions in many ways -- from community conversations, data we collect, research interviews we do, and more. This is not the first time we're asking and learning about many of these things–and we have already been doing work around many of them! We want to ask them again now and keep learning, as they are top of mind for us at this stage of our planning.

Questions:

Metrics and data
- What are some ways that data and metrics could better support your work as editors? Can you think of data about editing, reading, or organizing that would help you choose how to spend your time, or when something needs attention? This could be data about your own activity or the activity of others.
Editing
- When does editing feel most rewarding and fun for you? When does it feel most frustrating and difficult?
- We want contributors to receive more feedback and recognition for their work, so it doesn’t feel like nobody notices the effort they spend on the wikis. What kind of feedback and recognition is motivating to you? What nudges you to keep editing?
- Because the wikis are so large, it can be hard for editors to decide what wiki work is most important for them to spend their time on each day. What information or tools could help you choose how to spend your time? Would it be useful to have a central, personalized place that allows you to find new opportunities, manage your tasks, and understand your impact?
- We want to improve the experience of collaboration on the wikis, so it’s easier for contributors to find one another and work on projects together, whether it’s through backlog drives, edit-a-thons, WikiProjects, or even two editors working together. How do you think we could help more contributors find each other, connect, and work together?
Reading/Learning
- The wikis load faster or slower depending on where in the world people live. Are there any parts of the world where you think that improved performance is most needed?
- How can we help new generations of readers find Wikipedia content interesting and engaging? We’ve discussed ideas around interactive content and video in the past, and in the current year have focused on experimenting with new ways to surface existing Wikipedia content. How might we continue on this track to use our existing content in new ways that are unique to Wikimedia?
Moderators
- What might need to change about Wikipedia in order for more people to want to get involved in advanced volunteer roles, like patrollers or administrators?
- What information or context about edits or users could help you make patrolling or admin decisions more quickly or easily?
External Trends
- What are the most important changes you’re noticing in the world outside Wikimedia? These might be trends in technology, education, or how people learn.
- Outside of the Wikimedia movement, what other online communities do you participate in? What lessons can we take away from tools and processes on other community platforms?
- How are you using AI tools inside and outside your Wikimedia work? What do you find AI useful for?
Commons
- What decisions can we make with the Commons community to create a sustainable project that supports creating encyclopedic knowledge?
Wikidata
- How would you like to see Wikidata evolve in the future? How can it be most useful for building trustworthy encyclopedic content?

Discussion

–– Selena Deckelmann